문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 한영 키 (문단 편집) == 특유의 동작방식으로 인한 문제점들 == 한영키는 겉보기엔 다른 평범한 키들과 아무 다를바 없어 보이지만, 한국어 사용자들만 사용한다는 당연한 사실 이외에도 아주 큰 차이가 하나 있다. 누를 때와 뗄 때 모두 관련 신호가 발생하는 다른 키들과 달리, '''이 키는 누를 때에만 신호가 발생한다.''' 즉, 언제 눌렀는지는 알 수 있으나 언제 떼었는지는 알 수가 없는 것이다. 키보드 스캔 코드를 보여주는 프로그램으로 한영 키 입력을 해보면 쉽게 알 수 있다. 키보드 업체에서 인위적으로 떼었을 때의 신호를 발생시키고 싶어도 관련 표준 코드 자체가 존재하지 않아서 불가능하다. 이는 운영체제나 소프트웨어 등과 전혀 무관한, 먼 옛날 MS-DOS시절 한글 키가 맨 처음 발명되었을 때 같이 도입된 제약점이다. '''같은 시기에 도입된 [[한자 키]]도 동일한 특성이 있다.''' 왜 굳이 저렇게 처리했는지의 이유는 불명인데, 뗄 때의 신호를 생략한다 해도 따로 생기는 이득따윈 없으므로 여러모로 크게 아쉬운 일이다. 사실 이 키들의 용도를 감안하면 일반적인 상황에서는 별 문제가 없긴 하다. 한영전환을 가지고 음입력을 할 일도 없고, 누르는 순간에 한영 전환만 제대로 되면 그만일 따름이니까. '''그런데 한영 키를 다른 용도로 전환하고 싶다면 큰 문제가 된다.''' 떼는 시점을 알 수 없기 때문에 키 전환 시 일정 딜레이 후 키를 떼는 코드까지 추가로 에뮬레이션해야 하고, 떼는 시점을 반드시 정확하게 알아야 하는 modifier(조합키)계열(shift, ctrl, alt, win 등)의 용도로는 전환해서 쓰는 것이 사실상 불가능해져 버린다. 다만 여기까지는 별도의 키로 존재하는 한영 한자키를 굳이 다른 용도로 전환할 사람은 별로 없기 때문에 큰 문제가 아니다. 진짜 문제는 일부 우측 ALT/CTRL의 키 신호를 완전히 제거해버리고 펌웨어상으로 한영 한자키 키코드를 직접 발생하게 만들어진 키보드에서 발생한다. 이 경우는 무슨 수를 써도 해당 키를 본래 용도인 ALT/CTRL 용도로 쓸 수 없게 된다. IME에서 두 키를 한영 한자키로 전용하는 방법을 제공하는데도 굳이 저런 식으로 추가 처리를 해야 될까 싶지만 실제로 이런 제품들이 존재한다.[* 멤브레인 [[텐키리스]]인 스카이디지탈 2300LED가 이 방식이고, 이외에도 더 존재한다.] 왜냐하면 소프트웨어 설정 문제인데도 한영 키 입력이 안된다며 키보드의 고장 반품을 요구하는 사람들이 존재하기 때문. 키보드 제조사 입장에서는 매우 억울한 일이겠지만 이게 키보드의 잘못이 아니라는 해명을 쉽게 납득할 소비자라면 해당 건으로 반품 요청을 하지도 않을 것이다. 결국 이런 경우를 원천봉쇄하려면 펌웨어단에서 아예 한영 한자키 코드를 발생시키는 게 답이긴 하다. 그런데, 하필 '''키를 뗄 때의 신호가 없다'''는 한영 한자키의 태생적 문제점이, 영문 레이아웃에서 전용할 키가 ALT/CTRL이라는 '''떼는 시점을 반드시 알아야만 하는''' 키들이라는 특성과 역 시너지를 내는 바람에, 영문 이용자나 shift-space등으로 한영전환을 한다는 등의 이유로 우측ALT/CTRL을 본래의 기능으로 쓰고 싶은 소비자들이 예기치 않은 낭패를 보게 된다. 사실, 한영키(그리고 한자 키) 의 진정한 골치아픔은 그 입력 키 코드 자체에 있다. 키보드의 각 키는 스캔코드(Scancode)라는 이름으로 표준화된 신호를 각자 가지고 있는데, 누를 때 Make code를 생성하고, 뗄 때 Break code라는 다른 신호를 생성해서 '눌렀다', '떼었다' 를 구분하여 알려 준다. 이것을 처리하기 쉽게 하기 위해, 암묵적으로 누를 때의 신호(Make code) 에 0x80(10진수 숫자 128)을 더하면 뗄 때의 신호(Break code)가 되도록 지정해 두었기 때문에 각 컴퓨터 운영체제나 기타 전자장비들의 키보드 장치 드라이버는 0x80보다 크냐 작느냐를 기준으로 키보드 입력 처리를 하는 것. 그런데 한영키는 특이하게도 Break code 없이 Make code 만 0xF2(242)라는 특이한 코드를 가지고 있어, 이 신호를 받은 운영체제는 이것을 별도의 특수키의 신호 일부이거나 알수 없는 키의 Break code로 인식하고 예외 처리를 하는 것. 윈도우에서 한글 키보드를 인식시키기 위해서는 반드시 101키 1종~3종이니, 106 키보드니 하는 종류를 지정해 줘야만 하고, 일반적인 영문 키보드 드라이버로 인식된 상태에서 소프트웨어 혹은 레지스트리 등으로 개별 키를 추가로 매핑해서 할 수 없는 이유가 이것이다. 장치 드라이버 단계에서 한글(한자) 키에 대한 예외처리를 가장 먼저 해 주지 않으면 그 이후에서 무슨 방법을 써도 한영키를 구분해 낼 수가 없기 때문. 따라서 리눅스 같은 경우에도 특정 버전에서 setkeycodes 72 122 명령 등으로 드라이버 단계 인식 코드번호를 지정해 주거나, 드라이버에 한국어 키보드에 대한 예외처리를 따로 내장시키거나 하는 식으로 처리하는 등, 각 운영체제나 장비 별로 시스템 단계에서 제각기 다른 드라이버를 쓰므로 각기 다른 별도의 처리가 필요하다. 이제 윈도우에서 한영/한자 키와 Alt Ctrl 키를 자유롭게 선택해서 사용할 수 없고, 키보드 타입에 따라 사용방식이 고정되어 있는 이유도 이해가 갈 것이다. 아예 드라이버 단계에서 별도의 처리를 해 줘야 하기 때문. 만약 이런 부분에 민감한 사람이라면 그냥 속편하게 영문판 키보드를 사는 것이 좋다. 영문 키보드에는 한영 한자키 관련 추가 펌웨어 처리가 들어갈 이유가 전혀 없고, 반드시 스페이스바 양 옆에 한자 한영키가 있어야 하는 사람만 아니라면 자판만 외우면 영문 키보드도 아무 문제없이 한글 입력에 사용할 수 있으니까. 이런 특성은 커스텀 키보드의 펌웨어를 제작할 때에도 귀차니즘을 유발하는 요소로 작용한다. 다른 키들은 눌렀을 때에 코드 한 번, 뗐을 때에 코드 한 번 이렇게 일괄적으로 처리 가능한데 한영 한자키만 뗐을 때의 신호를 일부러 따로 무시해줘야 하기 때문. 펌웨어 코딩만으로 그냥 해결되는 부분이니 별 일은 아니지만 분명 귀찮은 일이다. 그래서 커스텀 키보드 제작을 할 때에는 키의 수도 줄이고 돈도 아낄 겸 해서 한영 한자키를 굳이 넣지 않고 그냥 우측 ALT/CTRL키만 구현한 뒤 운영체제를 통해 해당 두 키를 한영 한자키로 처리하도록 하는 쪽을 택하는 경우가 많다. 한자/한영키가 있는 기계식 키보드는 스페이스바를 찾기가 힘든데 이점은 '''금속접점이 없는 광축용 스위치'''로 한영 한자를 교체하면 '''6u나 7u스페이스바를 호환'''할 확률이 '''기하급수적으로 커진다.''' 광축스위치는 광센서 없이는 동작하지 않기 때문이다.저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기